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SECTION  1 


INTRODUCTION 

The  purpose  of  this  paper  is  to  illuminate  the  various  issues  concerned  with 
the  development  of  a  nuclear  survivability  validation  (SV)  protocol  for  a  system-of- 
systems  (SOS).  We  consider  these  issues  in  the  context  of  a  battle  management 
command,  control,  and  communications  (BMC^)  network  in  the  form  of  the 
Hypothetical  System  Architecture  (HSA)  described  below.  At  the  SOS  level,  the 
highest  possible  level  of  integration  (LOI),  survivability  validation  will  require  a 
combination  of  software  and  hardware  tools.  The  SV  protocol  must  validate  the 
nuclear  survivability  of  the  BMC^  SOS,  which  involves  considering  the  combined 
susceptibilities  of  both  the  SOS  platforms  and  the  communication  links. 

A  survivability  validation  protocol  is  a  pre-defined,  ordered  set  of  tools  and 
procedures  which  must  be  applied  to  a  specific  object  to  validate,  with  a  measurable 
statistical  confidence,  the  capability  to  perform  a  specified  mission  function  in  a 
defined  environment  resulting  from  a  specified  threat  class.  Application  of  the 
protocol  produces  a  documented  collection  of  data  establishing  auditable  traceability 
through  the  system  SV  process.  The  protocol  must  include  detailed  prescriptions 
for  the  combination  of  validation  tests,  simulations,  and  analyses  required  to 
exercise  the  SOS  in  order  to  show  that  it  is  survivable  in  a  nuclear  engagement, 
regardless  of  individual  platform  or  link  susceptibilities. 

A  survivability  regimen  is  a  set  of  survivability  validation  protocols  required 
to  assure  the  specified  performance  of  the  system  for  its  validated  threat.  The 
survivability  regimen  would  be  defined  in  the  Test  and  Evaluation  Master  Plan 
(TEMP)  by  the  Program  Management  Office  and  approved  by  the  acquisition 
authority  at  Milestone  I.  However,  changes  to  the  TEMP  during  the  system  lifecycle 
may  require  refinement  to  the  regimen  to  accommodate  those  changes. 

The  BMC^  SOS  protocol/ regimen  builder  is  the  "user"  of  products  developed 
by  technologists  familieu:  with  the  test  and  analysis  of  systems,  ^th  the  user  and  die 
technologist  currently  have  problems  developing  and  applying  survivability 
validation  protocols  at  this  level  of  integration.  The  problem  for  the  technologist  is 
that,  for  the  SOS  level  in  particular,  the  tools  that  he  would  use  to  create  the 
protocols  are  not  well  enough  developed  or  available  for  practical  use.  For  example, 
there  really  are  no  facilities  available  for  SOS  testing,  as  there  are  for  lower  levels  of 
integration.  The  problem  facing  the  "user"  is  the  complete  absence  of  survivability 
validation  protocols  at  the  SOS  level. 

During  the  development  of  the  BMC^  SV  regimen,  engagement  scenario 
simulations  will  be  used  to  determine  quantitative  requirements  to  be  levied  on  the 
platforms  comprising  the  SOS.  The  engagement  scenario  simulations  will  ideally  be 
part  of  requirements  generation  process.  These  simulations  may  be  considered  part 
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of  the  regimen  because,  at  the  SOS  level,  the  survivability  strategy  must  consider  the 
means  of  validating  survivability  at  the  outset.  The  SV  protocols  for  the  lower 
levels  of  integration  will  either  validate  that  the  platforms  meet  requirements  or 
will  determine  the  attained  survivability  levels,  which  may  be  higher  or  lower  than 
the  requirements. 

Survivability  is,  of  course,  not  necessarily  attained  only  through  hardness. 
However,  the  overall  BMC^  regimen  incorporating  all  lower  level  protocols,  will 
involve  selected  hardness  requirements.  That  is,  certain  platforms,  subsystems, 
components,  and  parts  will  be  hardened  to  withstand  some  specific  level  of  relevant 
nuclear  environments.  The  hardness  level  will  be  determined  by  standard  effects 
balancing  considerations  based  on  engagement  scenarios  performed  earlier  in  the 
life  cycle.  It  is  plausible,  for  example,  that  survivability  of  the  SOS/BMC^  will  be 
attained  by  requiring  groimd-based,  air-based  and  sea-based  platforms  to  be  hardened 
to  a  High  Altitude  Electromagnetic  Pulse  (HEMP)  specification,  while  achieving 
survivability  to  all  other  prompt  and  persistent  effects  through  redundancy, 
avoidance,  maneuverability,  reconstitution,  etc.  Protocols  at  lower  LOIs,  which  are 
part  of  the  regimen,  would  then  involve  characterizing  the  survivability 
performance  (and  degradation)  via  effects  testing.  The  test  results  could  then  be 
provided  to  those  executing  the  SOS-level  protocol  to  use  in  simulations  and  tests  at 
the  SOS  level. 

The  following  sections  will  discuss  the  Hypothetical  System  Architecture,  the 
nuclear  effects  that  must  be  modeled  in  the  simulation,  validation  test  concepts  to 
be  considered,  the  validation/pedigree  of  the  nuclear  environments  and  effects 
models/codes,  and  other  SOS  SV  protocol  simulation  code  issues.  The  concluding 
remarks  highlight  the  most  likely  way  of  simulating  nuclear  effects  and  the 
continued  need  for  a  configuration  control  program  for  simulation  tools. 
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SECTION  2 


HYPOTHETICAL  SYSTEM  ARCHITECTURE 

Ihe  HSA  that  will  be  used  to  illustrate  a  complex  SOS  is  a  generic  BMC^ 
system.  It  contains  air-,  space-,  sea-,  and  land-based  components  as  shown  in  Figure 
2-1.  Table  2-1  contains  a  short  description  of  the  various  links  and  platforms  that  are 
represented  in  the  HSA.  The  mission  of  the  HSA  is  to  detect,  track,  and,  upon 
command,  intercept  and  destroy  by  non-nuclear  means,  at  least  X%  of  up  to  Y 
incoming  ICBM/SLBM  re-entry  vehicles  (fired  singly,  rippled,  or  in  salvo),  with  an 
associated  confidence  of  C%.  The  system  must  survive  and  operate  in  a  nuclear 
environment.  The  definition  of  nuclear  survivability,  per  DoDI  5000.2  (and  DoD 
Dir  5000.1),  is  "the  capability  of  a  system  to  avoid  or  withstand  man-made  hostile 
environments  without  suffering  an  abortive  impairment  of  its  ability  to  accomplish 
its  designated  mission." 

During  HSA  operation,  the  flow  of  information  is  from  one  or  more  of  the 
space-based  laimch  sensors  to  one  or  more  of  the  communications  satellites.  These, 
in  turn  relay  the  information  between  satellite  platforms  and  the  respective  surface 
and  airborne  sites  (North  American  Air  Defense  Command  (NORAD),  trackers, 
interceptor  control  center.  Airborne  Command  Post  (ABCP),  and  various  sea 
platforms).  The  information  from  the  space-based  mid-course  tracker  flows  along 
the  same  path.  Information  from  the  sea  and  groimd  platforms  is  fed  into  the 
central  command  facility  (which  in  this  case  is  NORAD).  Command  and  Control 
information  flows  from  the  central  command  facility  to  the  sensor  and  command 
sites.  Once  the  launch  decision  is  made  the  interceptor  control  center 
communicates  with  the  groimd-based  final  tracker,  NORAD,  and  the  interceptor  to 
guide  the  interceptor  to  its  target. 

Each  platform  will  be  assiuned  to  have  been  subjected  to  its  own  SV 
protocols,  liiis  means  that  the  protocol  for  the  SOS  will  probably  require  the  use  of 
an  SOS  simulator  which  will  request  survivability  information  from  subordinate 
platform  protocols.  For  some  of  the  platforms  (such  as  the  Airborne 
Communications  Node,  Groxmd-Bas^  Final  Tracker,  etc.),  a  functional  test 
simulator  may  be  used  to  assess  the  platform  operation  in  the  presence  of  normal  or 
nuclear  environments.  It  is  assumed  that  any  such  individual  system  simulators 
will  have  been  validated  for  normal  operational  environments  and  that  each  will 
adequately  stress  the  system  tmder  normal  operating  conditions.  A  nuclear 
environment  simulator  may  consist  of  these  basic  simulators  modified  to  include 
nuclear  effects. 


3 


Figure  2-1.  Hypothetical  system  architecture. 


Table  2-1.  Hypothetical  system  architecture  description. 

CATEGORY  ELEMENT/UNK(S)  ABBREVIATION  FUNCTION/COMMENTS 

Sensof  Space  Based  Launch  PetectifKi  Sensor  SB  L»inch  Sensor _ Bell-rinaina  launch  detection 
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Comm  Link  P  CC  <-->  SB  Comm  Node _ Ground  <-->  Space  link _ 

Comm  Link  Q  CC  <->  GB  Final  Tracker _ Landline  link _ 

Comm  Link  R  CC  <-->  GB  Exo  Interceptor _ Landline  link  +  ground  <-->  space  for  status/handoff 


There  may  have  to  be  an  additional  computer  for  the  nuclear  simulation 
management.  This  simulation  management  system  would  coordinate  the 
simulated  attack  burst  locations  and  times,  and  turn  on  any  hybrid  simulations  at 
the  proper  times  and  levels  (e.g.,  link  simulators,  scene  generators).  A  hybrid 
simulation  is  defined  as  a  simulation  that  includes  hardware  and/or  man-in-the- 
loop  in  addition  to  software.  This  approach  requires  that  the  potential  effects  of 
nuclear  bursts  on  all  of  the  platforms  and  links  in  the  architecture  must  be  modeled, 
or  represented  in  some  fashion.  However,  due  to  the  many  possible  engagement 
scenarios  and  associated  ranges  of  environments  involved,  the  simulation  must  be 
able  to  parametrically  inject  die  effects  of  the  nuclear  environment  on  each  platform 
to  determine  if  it  is  destroyed,  degraded,  or  fully  operational.  If  a  particular  platform 
or  link  is  not  able  to  perform  its  fimction,  dien  the  simulation  should  verify  that 
the  SOS  is  adequately  re-configured  to  perform  its  mission. 
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SECTIONS 


NUCLEAR  EFFECTS  TO  BE  CONSIDERED 

The  HSA  described  above  involves  platfonns  deployed  in  many  different 
altitude  regimes,  and  thus  various  SOS  platforms  can  be  exposed  to  both 
endoatmospheric  and  exoatmospheric  nuclear  bursts.  These  environments  contain 
both  prompt  and  persistent  components  which  could  degrade  the  individual 
platform’s  capabilities  and  performance,  and  yet  allow  the  overall  SOS  to  survive 
the  nuclear  scenario  and  complete  its  mission. 

The  prompt  environments  generally  pose  a  damage  (or  upset)  concern  to  the 
platforms  that  comprise  the  SOS,  while  the  persistent  environments  pose  both 
damage/upset  as  well  as  operability  (signal-to-noise)  problems.  Both  must  be 
addressed  in  the  SV  protocol  at  the  SOS  level,  but  it  will  generally  be  true  that  real 
tests  (hardware  simulations)  of  the  actual  BMC^  system  will  only  test  operability 
since  we  cannot  afford  to  permanently  damage  any  portion  of  it  in  a  test;  actual 
damage  causing  environments  and  effects  must  be  investigated  and  characterized  at 
lower  levels  of  integration.  These  damage-causing  effects  can  be  represented  in 
hardware-in-the-loop  tests  through  the  use  of  so^are  simulations  of  selected 
platforms  (for  example,  in  an  algorithm  that  removes  the  platform  from  the  SOS 
when  a  simulated  nuclear  environment  level  is  above  a  specified  threshold). 

There  are  some  nuclear  environments  that  are  well  imderstood  and  that 
have  well  characterized  nuclear  effects;  for  example,  those  prompt  environments 
and  effects  which  can  be  studied  in  underground  effects  and  device  tests.  By 
contrast,  there  are  some  environments  and  effects  that  are  not  as  well  imderstood 
due  to  limited  or  non-existent  data;  this  tends  to  be  the  case  with  persistent 
environments,  where  nuclear  tests  are  not  possible. 

The  potential  susceptibilities  to  nuclear  effects/environments  considered  in 
this  section  are  for  illustrative  purposes  only.  However,  they  are  typical  of  the 
matrix  of  potential  susceptibilities  that  must  be  identified  and  documented  to 
develop  a  protocol  for  an  BMC^  SOS.  The  SV  protocol  must  consider  these 
potential  susceptibilities,  and  must  exercise  them  in  tests  and  simulations  to 
validate  survivability  of  the  SOS.  The  selected  environments  illustrate  the  scope  of 
the  nuclear  environment  effects  that  must  be  considered  when  validating  the 
survivability  of  a  system-of-systems. 

Per  DoD  Instruction  5000.2,  susceptibility  is  defined  as  "the  degree  to  which  a 
device,  equipment,  or  weapon  system  is  open  to  effective  attack  due  to  one  or  more 
inherent  weaknesses.  Susceptibility  is  a  function  of  operational  tactics, 
countermeastu^s,  probability  of  enemy  fielding  a  threat,  etc.  Susceptibility  is 
considered  a  subset  of  survivability." 
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Thus  susceptibility  refers  to  the  potential  for  damage  or  degradation  in  a 
platform  or  link  due  to  an  effect  or  an  environment.  For  example,  if  it  can  be 
argued  that  an  rf  communication  link  will  be  affected  by  a  nuclear  disturbed 
environment  in  the  form  of  a  high  electron  density,  then  that  link  is  potentially 
susceptible  to  nuclear  disturbed  electron  densities.  It  follows  that  the  SV  protocol 
must  consider  this  effect/ environment  in  its  validation  of  nuclear  survivability. 
This  view  recognizes  that  there  are  some  effects /environments  which  do  not  pose 
threats,  and  hence  do  not  have  to  be  considered  in  any  tests  or  simulations  within 
the  SV  protocol.  Examples  would  be  those  that  can  be  immediately  dismissed  such 
as  electromagnetic  pulse  (EMP)  on  geosynchronous  satellites.  X-ray  effects  on 
ground  systems,  or  other  effects  that  can  be  shown  to  be  entirely  insignificant 
through  analysis.  The  point  is  that,  if  an  environment /effect  has  an  entirely 
negligible  effect,  it  need  not  be  included  in  any  protocol  simulations  or  tests.  This  is 
in  accord  with  conventional  hardening  protocols  at  lower  levels  of  integration, 
where  tests  and  detailed  modeling/ computer  simulations  are  only  done  on  aspects 
that  there  is  reason  to  believe  (based  on  analysis  by  experts)  are  important,  i.e.,  on 
potential  susceptibilities. 

The  individual  platforms  and  links  of  the  HSA/BMC^  are  assigned 
susceptibilities  to  endoatmospheric  and  exoatmospheric  nuclear  enviroiunents  as 
presented  in  Table  3-1,  where  considerations  were  given  to  both  vulnerability 
(damage  and  upset)  and  operability  (system  operation  in  the  presence  of  nuclear 
disturbances).  To  validate  the  survivability  of  an  SOS,  nuclear  environments  and 
effects  to  which  the  SOS's  links  and  platforms  are  susceptible  must  be  considered. 
Hardness  of  the  platforms  to  specified  environments  or  effects  (Electromagnetic 
pulse,  transient  radiation  effects  on  electronics,  thermo-structural  response,  etc.)  is 
assiuned  to  have  been  validated  in  protocols  at  lower  levels  of  integration.  Platform 
svisceptibilities  are  of  course  not  limited  to  cases  where  platform  deployment 
altitude  and  biirst  altitude  are  comparable;  that  is,  some  platforms  with  an 
endoatmospheric  basing  mode  may  experience  some  exoatmospheric 
enviroiunents.  For  example,  ground-  and  sea-based  platforms  are  susceptible  to 
HEMP  environments  as  specified  in  the  DOD-STD-2169A.  In  this  example,  we 
consider  commimication  links  consisting  of  land  line  links  to  be  susceptible  to 
grotmd  motion,  but  not  EMP  or  gamma  dose  rate  (i.e.,  rf  and  gamma  shielded  lines 
are  assumed). 
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Table  3-1.  HSA  potential  susceptibilities. 
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SECTION  4 


VALIDATION  TESTING  CONCEPTS 

Here  we  consider  prospective  test  concepts  that  apply  at  the  SOS  level.  There 
are  several  considerations  peculiar  to  this  level  of  integration; 

•  Unlike  platform  and  lower  levels  of  integration,  the  SOS  is  not  portable  in 
any  sense,  since  it  involves  "buildings"  or  other  permanently  installed 
ground-based  platforms. 

•  It  is  extended  in  space  so  that  not  all  of  the  platforms  experience  the  same 
nuclear  environment  (unlike  the  case  for  platforms,  there  is  no  nuclear 
environment  that  is  externally  uniform  over  the  SOS).  As  a  result,  there  are 
many  combinations  of  possible  environments. 

•  SOS  nuclear  survivability  must  be  referenced  to  a  range,  or  variety,  of  possible 
engagement  scenarios,  rather  than  in  terms  of  hardening  to  a  range  of 
possible  point  environments  (as  it  is  for  platforms,  where  a  range  of 
environments  or  requirements,  or  "specs",  "flow  down"  from  earlier  SOS 
simulations). 

•  An  actual  test  modeling  a  real  nuclear  environment  is  not  possible  (as  it  is  for 
some  lower  levels,  where  imdergroimd  nuclear  tests  (UGT’s)  can  be  used, 
assiuning  they  remain  a  testing  option). 

Survivability  to  some  effects  is  implemented  at  lower  levels  of  integration  in 
the  form  of  hardness  to  some  specified  threat  (which  early  in  the  development 
phase  is  a  requirement  that  "flows"  down  from  engagement  scenarios  at  the  SOS 
level).  An  example  would  be  HEMP,  where  hardness  to  HEMP  is  still  required  as 
the  way  to  achieve  survivability  to  this  environment.  Other  environments  may 
not  require  hardening,  however,  but  may  require  other  methods.  We  emphasize 
that  sxuvivability  can  be  attained  by  methods  other  than  hardness.  DoDI  5000.2 
emphasizes  the  need  to  consider  and  implement,  when  most  cost  effective,  other 
methods  such  as  proliferation,  redimdancy,  reconstitution,  avoidance,  deception, 
active  defense,  and  tolerance  to  the  effect.  For  those  environments/effects  where  a 
hardness  requirement  is  involved,  lower  level  SV  protocols  must  validate  that  this 
required  hardness  level  was  in  fact  attained.  We  may  still  view  this  as  a  platform 
susceptibility,  but  only  for  stresses  (or  levels)  in  excess  of  the  requirement.  For 
environment  levels  above  the  requirement,  SV  protocols  might  involve  tests  or 
simulations  where  the  platform  is  regarded  to  fail  for  levels  above  the  requirement. 
For  example,  a  "cookie  cutter"  module  for  incorporating  prompt  nuclear  effects  in  a 
system  simulation  is  illustrated  in  Figure  4-1.  This  is  similar  to  the  simulation 
concept  in  Riley  et  al.,  1991.  A  generalization  to  include  persistent  effects  may  also 
be  possible,  but  poses  difficult  timing  problems.  Alternatively,  if  the  lower  level 
protocols  involved  evaluating  or  characterizing  the  performance  degradation  for 
levels  above  specifications,  then  degradation  or  fragility  curves  could  be  used  in  any 
tests  or  simulations  specified  in  the  SOS  protocol. 
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Figure  4-1.  Prompt  effects  module. 
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It  is  clear  from  these  considerations  that  validation  testing  will  be  quite 
difficult  and  will  pose  special  problems  at  the  SOS  level.  The  general  categories  of 
tools  that  may  be  available  for  application  in  any  SOS  SV  protocol  will  consist  of  : 

(1)  Software  simulations. 

(2)  Scene  generators  and  link  simulators. 

(3)  Special  hardware  that  can  be  airborne  or  space-based  to  simulate  nuclear 
disturbed  atmospheric  conditions/effects. 

(4)  Special  hardware/computers/software  packages  or  models  used  to  exercise 
portions  of  the  SOS. 

(5)  Special  hardware  and  procediures  to  represent  a  specific  nuclear  effect/ 
environment. 

Category  (1)  refers  to  purely  computer  simulations  of  the  SOS,  wherein  a  wide 
variety  of  engagements  and  combinations  of  environments  can  be  considered.  This 
tool  corresponds,  for  example,  to  "level  2"  of  ti\e  National  Test  Bed  (NTB) 
simulator,  where  SOS  survivability  is  validated.  It  is  to  be  distinguished  from  the 
"level  1"  simulations,  where  hardness /balancing  is  coi^idered  to  derive 
requirements  on  platforms,  subsystems,  etc. 

Category  (2)  refers  to  special  purpose  hardware  and  software  that  simulate 
disturbed  environments  for  radar,  commxinication  links,  and  optical  sensors.  Thus 
target  acquisition,  discrimination,  communication,  etc.,  can  be  exercised  in  the 
complicating  presence  of  nuclear  disturbances  (which  generally  cause  signal-to-noise 
or  operability  problems).  Designers  of  the  Safeguard  system,  for  example,  planned  to 
use  a  system  exerciser  to  drive  the  radar  (at  an  injection  point  beyond  the  phased 
array  elements)  to  simulate  battle  engagements.  Another  example  is  the  Strategic 
Defense  Conunand  (SDC)  Portable  Radiation/Redout  Testbed  for  Sei\sors  (PORTS) 
test  concept,  which  is  an  end-to-end  test  of  an  optical  sensor  subsystem.  The  hybrid 
simulation  concept  is  illustrated  in  Figure  4-2,  where  the  "balloons"  connected  to 
the  platforms  via  'Tjubbles"  represent  software  driven  simulations.  In  this 
illustration,  we  have  considered  a  Grovmd-Based  Exoatmospheric  Interceptor  (GBEI) 
platform  to  be  replaced  by  a  launch/fly  out  simulation;  we  have  also  depicted  each 
of  the  air,  sea,  and  land-based  platforms  as  subjected  to  some  degree  of  simulated 
nuclear  environment. 

Category  (3)  refers  to  such  things  as  barium  rocket  canister  techniques,  where 
the  atmosphere  is  actually  ionized  to  some  extent,  just  as  it  would  be  from  a  nuclear 
burst.  Metallic  reflectors  placed  within  the  atmosphere  to  interfere  with  radio 
transmission  to  simulate  a  nuclear  disturbed  atmosphere  would  be  another 
example.  Of  course,  it  is  clear  that  a  number  of  difhcult  simulation  fidelity  problems 
will  be  posed  by  any  of  these  techniques.  Also,  the  cost  may  be  prohibitive. 
Moreover,  based  on  recent  discussions  with  the  Defeitse  Nuclear  Agency's 
Atmospheric  Effects  Division  (DNA/RAEE),  the  barium  caiuster  technique  appears 
to  generate  inadequate  ionization  to  interfere  with  an  rf  link. 
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Hybrid  simulation  concept. 


Category  (4)  refers  to  special  hardware  and  software,  such  as  auxiliary 
comrnter  networks,  that  would  exercise  portions  of  the  system,  or  perhaps  replace 
specific  platforms.  For  example,  the  Groimd-Based  Exoatmospheric  Interceptor 
(GBEI)/C2  interface  in  our  HSA  could  be  simulated  by  a  special  GBEI  flight 
simulator  software  package. 

Category  (5)  refers  to  such  things  as  blast  simulations  or  current  injection 
devices,  to  simulate  the  effect  of  a  degrading  nuclear  environment  (e.g.  air  blast  or 
EMP).  It  is,  of  course,  assumed  for  the  SOS  SV  protocol  that  protocols  at  platform 
and  lower  levels  of  integration  have  already  been  executed  to  validate  (or  quantify) 
survivability/hardness  of  that  particular  platform.  Thus,  it  would  not  make  sense 
in  category  (5),  to  use  actual  damage-causing  levels  of  an  effect/environment  (since 
we  cannot  afford  to  break,  or  damage,  an  expensive  SOS),  but  reversible  degradation 
could  conceivably  be  included.  An  example  of  this  category  is  the  use  of  current 
injection  into  a  C^  facility  to  exercise  its  response  mechanisms. 

Another  salient  point  regarding  the  above  categories  of  tools  is  that  while 
they  can  apply  throughout  the  lifecycle  of  the  system,  some  may  be  more  applicable 
to  certain  life^cle  phases  than  others.  Category  (1)  can  and  should  be  used  to 
validate  survivability  early  in  the  development  phase,  where  the  SOS  is  in  the 
design/planning  stage.  However,  category  (1)  will  continue  to  be  important 
throughout  the  development  phase,  as  it  allows  the  most  flexibility,  the  most 
extensive  and  varied  tests,  and  is  the  least  expensive  kind  of  simulation.  Categories 
(2)  through  (5),  on  the  other  hand,  assume  that  portions  of  the  SOS  actually  are  built 
and  available  for  testing,  at  least  in  the  form  of  prototypes. 

Another  point  is  that  validation  of  the  fielded  SOS  (deployment  phase)  is 
something  that  can  be  continued  with  the  system  exerciser  concept.  A  system 
exerciser  capability  could  be  tailored  to  validate  survivability  and  "availability" 
(readiness)  periodically  throughout  an  SOS  deployment.  This  is  an  extension  of  the 
hardness  maintenance/hardness  assurance  concept  for  platforms  and  subsystems. 
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SECTION  5 


SOS  SV  PROTOCOL  SIMULATION  CODE  ISSUES 

As  alluded  to  earlier  in  this  paper,  the  prospect  of  testing  a  complex  SOS  in  an 
actual  nuclear  environment  short  of  a  nuclear  war  is  non-existent.  Thus,  the 
highest  confidence  approach  to  an  SOS  protocol  will  probably  involve  some 
combination  of  software  simulations  and  hybrid  simulations,  where  hybrid 
simulations  are  combinations  of  software,  hardware,  and  man-in-the-loop  used  in 
concert  to  provide  the  desired  simulation. 

Computer  codes  could  be  used  in  both  purely  software  simulations  as  well  as 
hybrid  simulations.  The  relevant  codes  at  the  SOS  level  will  be  used  to 

(1)  Calculate  prompt  environments  (gamma.  X-ray,  EMP,  blast,  etc.)  on  the 
various  platforms  for  a  given  simulated  burst  location, 

(2)  To  calculate  persistent  environments  on  a  global  scale,  and 

(3)  To  calculate  effects  of  the  persistent  environments  on  links,  radar,  and 
sensors. 

These  persistent  effects  involve  blackout,  redout,  and  clutter.  They  generally  pose 
signal-to-noise  problems,  and  hence  their  effects  can  also  be  hardware  simulated 
with  computer  code-driven  scene  generators  and  link  simulators  for  example.  One 
would  probably  not  use  codes  at  the  SOS  engagement  level  to  calculate  prompt 
damage/upset  effects,  as  these  would  be  characterized  off-line  and  in  lower  level 
protocols  (either  in  terms  of  pass/fail  or  degradation). 

Codes  of  the  t5^es  described  in  Table  5-1  have  dealt  with  some  of  these  issues 
(Faizullabhoy,  1992).  This  table  shows  some  examples  of  codes  that  would  be  used  to 
calculate  prompt  environments,  persistent  enviroiunents,  and  persistent  effects. 

Our  assessment  of  the  status  of  the  validation  and  documentation  is  also  indicated 
in  the  table.  Codes  of  this  type  could  either  be  combined  as  subroutines  into  the 
simulation  software,  or  will  have  to  be  represented  in  the  form  of  off-line  generated 
lookup  tables  or  other  types  of  data  bases. 

One  major  issue  in  any  BMC^  simulation  will  be  the  following:  what 
parameters  have  to  be  specified  in  a  nuclear  engagement.  For  example,  are  burst 
location,  yield,  and  time  sufficient  to  define  the  enviroiunent  and  effects?  In 
particular,  what  does  the  time  parameter  mean?  Is  it  relative  to  SOS  phases,  or  are 
there  state-of-the-universe  parameters  as  well  (solar  storms,  sun  and  moon  shine, 
day /night,  location  of  supporting  or  synergistic  military  systems  or  forces,  etc.).  The 
identification  of  parameters  that  are  of  concern  to  SOS  operations  is  one  of  the 
problems  conhronting  the  simulation  developer. 

Another  of  the  difficult  problems  facing  both  the  protocol  and  simulation 
designer  is  that  of  code  validation,  whether  the  code  is  true  to  the  real  world.  The 
plain  fact  is  that,  since  we  cannot  do  above-ground  (AG)  nuclear  tests,  there  is  no 
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Table  5-1.  Examples  of  computer  codes  for  SOS  SV  protocol. 


Validations 

OCXIB 

Brief  Description 

Comparison  with 
other  codes  and 
analysis 

Comparison  to 
Experimental 
Data 

Documentation 

Engagement  level  code  for  predicting 
nuclear  effects 

Yes,  based  on 
NORSE 

comparisons* 

No 

Available* 

MICE 

A  first  principles  code  for  calculating 
the  evolution  of  high-beta  plasma  in 
an  surrounding  fireball  and/or  kinetic 
energy  patch  regions  created  by  high 
energy  explosions 

Yes** 

Yes** 

Technical 

reports* 

MELT 

A  first-principles  code  for  calculating 
the  evolution  of  ‘low-beta*  plasma  in 
and  surrounding  'late-time*  fireball 
kinetic  energy  patch  plasma  that  has 
evolved  into  *high-altitude  nuclear- 
burst  plume.* 

Yes** 

Yes,  but 
limited** 

Technical 

Reports* 

NORSE 

Nuclear  Optical  and  Radar  Systems 
Effects;  state-of-the-art  system 
effects  code,  intermediate  between 
first-principies  physics  approach  and 
fast-running  codes  used  in 
engagement  simulations 

Yes** 

Yes,  for 

component 

models** 

Yes** 

HISEMM 

A  FORTRAN  caiiable  module  for  use  in 
global  engagement  simulations. 
Calculates  RF  and  IR  propagation 
efforts  in  a  multiburst  nuclear 
environment 

Yes,  based  on 
NORSE,  and 
SCENARIO 
comparisons* 

No 

Yes** 

SCENARIO 

A  physics-based  engineering 
simulation  tool  for  disturbed 
environments  resulting  from  multiple 
high-altitude  nuclear  explosions 

Yes** 

Yes** 

Yes* 

wecGM 

A  family  of  codes  for  calculating 
effects  of  normal,  nuclear,  and 
jamming  environments  on  comm  link 
performance 

Yes* 

Yes* 

Yes** 

SIMBAL  II 

A  fast-running  code  for  predicting 
nuclear  weapon-produced  propagation 
effects  on  individual  VLF,  LF,  and  HF 
links  in  large  communications 
networks 

Yes* 

Yes* 

Yes** 

*No  specific  references  given  in  the  DNA  Nuclear  Weapons  Effects  Code  Catalog 
**Specific  references  given  in  the  DNA  Nuclear  Weapons  Effects  Code  Catalog 


way  to  rigorously  validate  the  persistent  environment  codes.  True,  there  are  AG 
data  from  the  19^s  and  1960s,  but  these  tests  were  imcontrolled  and  the  data  are 
really  quite  limited.  Also,  normal  environments  can  be  used  to  provide  a  degree  of 
validation.  As  pointed  out  in  Hodges  et  al.,  1992,  a  code  that  cannot  be  validated  can 
still  be  useful;  however,  care  must  be  taken  that  the  code  includes  state-of-the-art 
physics  models  that  represent  the  complete  ensemble  of  effects. 

A  less  serious  problem,  but  one  that  should  be  mentioned,  is  code 
documentation.  Some  of  the  potentially  useful  codes  are  not  formally  documented. 
A  related  problem  is  the  tiser  friendliness  of  the  code.  Also,  the  simulation  fidelity 
versus  nm  time  consideration  is  a  concern.  It  will  undoubtedly  be  necessary  to 
compromise  on  high  fidelity  to  get  reasonable  real-time  responses.  (Stringer  et  al., 
1992) 


The  last  issue  to  be  discussed  is  that  of  configuration  control  of  the  SOS 
simvdation  tools.  Paragraph  2.a,  Policies,  on  page  6-F-2  of  DoDI  5000.2  states:  "The 
survivability  of  all  systems  that  must  perform  critical  functions  in  a  man-made 
hostile  environment  shall  be  an  essential  consideration  during  the  acquisition  life 
cycle  of  all  programs,  to  include  developmental  and  non-developmental  programs." 

The  next  paragraph  in  this  reference  states  that  survivability  from  all  threats 
(including  nuclear)  found  in  the  various  levels  of  conflict  shall  be  considered.  As  a 
result,  nuclear  survivability  is  to  be  considered  as  part  of  the  mission  needs 
statement.  Hence,  the  argument  can  be  made  that  the  tools  used  to  validate  the 
system  survivability  should  be  brought  imder  the  same  kind  of  configuration 
control  as  mission  critical  items. 

For  example,  the  Department  of  Defraise  has  developed  a  set  of  standards  to 
ensure  that  Mission-Critical  Computer  Resources  (MCCR)  software  is  developed 
with  the  necessary  rigor.  These  standards  include: 

(1)  DoD-STD-2167A,  Defense  System  Software  Development,  29  February 
1988. 

(2)  DoD-STD-2168,  Software  Quality  Evaluation 

(3)  MIL-STD-483,  Configuration  Management  Practices  for  Systems, 
Equipment,  Munitions,  and  Computer  Programs,  4  June  1985. 

(4)  MiL-STD-1521B,  Technical  Reviews  and  Audits  for  Systems,  Equipment, 
and  Computer  Programs,  4  June  1985 

DoD-STD-2167A  is  the  most  important  of  these  standards.  It  specifies  the 
products  to  be  produced  during  software  development,  requirements  to  be  satisfied 
by  the  development  process,  and  reviews  to  be  performed.  The  lifecycle  phases, 
deliverable  products,  reviews,  and  baselines  are  discussed  in  the  standard.  These 
products  axe  intended  to  provide  traceability  throughout  the  lifecycle.  Baseline 
products  cannot  be  aibitrarily  changed  without  undergoing  strict  configuration 
management  practices.  Software  testing  mandated  by  the  standard  is  fairly 
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comprehensive,  and  following  the  practices  of  this  (and  other)  standards  can  lead  to 
more  reliable  software. 
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SECTION  6 


CONCLUSIONS 

The  previous  sections  have  discussed  the  various  issues  involving  the 
development  of  an  SOS  protocol.  Based  on  those  issues,  the  following  are  a  few 
conclusions  regarding  the  development  of  such  a  protocol. 

(1)  It  appears  likely  that  the  SOS  protocol  will  have  to  rely  mainly  on 
computer  simulations,  with  some  assistance  from  hybrid  simulatioi\s  which 
involve  some  of  the  platforms,  links,  and  man  actually  being  "in  the  loop" 
(hardware-in-the-loop  and  man-in-the-loop).  These  hybrid  simulations  will 
involve  link  simulators  and  scene  generators  (for  optical  sensors  and  for  radar,  to 
simulate  "redout"  and  "blackout"  respectively).  A  serious  drawback  that  seems 
inescapable  at  the  present  time  is  that  none  of  the  actual  nuclear  environments  can 
be  present  "in  actuality"  in  tests  in  SV  protocols  at  the  SOS  level.  This  may  be  at 
odds  with  DoD  directives  which  require  that  survivability  validation  not  be  based 
solely  on  analysis.  (One  can  argue  that  computer  simulation  is  purely  analysis; 
furthermore,  hybrid  simulation  is  to  a  large  extent  based  on  analysis,  since  the  scene 
or  disturbed  atmosphere  is  based  on  a  calculated  or  modeled  environment.) 

Rimtime  and  simulation  fidelity  tradeoff  will  be  a  major  consideration,  made  more 
difficult  by  the  fact  that  many  modeled  features  of  the  persistent  environment  will 
not  be  amenable  to  validation. 

(2)  The  hybrid  simulation/system  exerciser  concept  can  also  be  of  use 
demonstrating  that  fielded  systems  retain  their  initial  survivability  (the  goal  of 
hardness  maintenance/hardness  surveillance).  A  general  concern  in  military 
systems  is  that,  while  they  might  be  survivable  when  initially  fielded,  they  may  not 
retain  this  survivability  as  the  system  ages.  This  concern  could  also  arise  in 
connection  with  an  SOS/BMC^.  With  a  testability  feature  designed  into  the  system, 
in  the  form  of  a  hybrid  simulation  capability  at  the  SOS  level,  the  simulation  feature 
could  serve  a  dual  purpose:  to  validate  survivability  in  the  beginning  of  the 
deplo3nnent  phase  as  well  as  during  deployment. 

(3)  At  the  present  time,  there  appears  to  be  little  hope  of  physically 
simulating  disturbed  enviroiunents  using  non-nuclear  techniques.  Even  if  such 
techniques  were  available,  it  may  be  desirable  to  use  them  off-line  to  validate 
software  tools  which  would  then  be  used  in  SOS  simulations. 

(4)  Configuration  control  of  the  SC^  simulation  tools  should  be 
considered  as  if  the  simulation  tools  were  mission  critical.  For  example,  simulation 
software  could  be  treated  in  the  maimer  described  in  the  previous  section  with  the 
nuclear  ejects  software  conforming  to  the  requirements  of  the  military  standards, 
such  as  DoD-STD-2167A  and  2168.  In  addition,  the  nuclear  effects  simulation 
hardware  could  conform  to  the  comparable  mission  critical  hardware  standards  for 
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documentation,  verification,  and  validation.  As  a  result,  DNA  should  consider 
controlling  the  simulation  tools  as  mission  critical. 
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